Introducción a la ingeniería de requisitos

Introducción

La ingeniería de requisitos es la disciplina que se encarga de obtener, analizar, documentar y validar los requisitos, y dado que estos pueden variar y evolucionar a lo largo del proyecto, las actividades de gestión serán fundamentales.

Un requisito es la capacidad, característica o factor de calidad del sistema, que aporta valor al cliente o usuario final y sirve de base del trabajo de diseño, desarrollo, pruebas y mantenimiento.

Concepto de requisito

Un requisito, definido desde diferentes puntos de vista, es:

• Una condición o capacidad que un usuario necesita para resolver un problema o lograr un objetivo. (Punto de vista del usuario)

• Una condición o capacidad que debe tener un sistema o un componente de un sistema para satisfacer un contrato, una norma, una especificación u otro documento formal. (Punto de vista del sistema)

• Una representación documentada de las anteriores. (Punto de vista de la documentación)

Dimensiones de los requisitos

• Ámbito: es la parte del sistema que se ve afectada por el requisito. Puede aportar información sobre el sistema en su conjunto, el hardware que lo soporta o las funcionalidades del software.

• Características: Podemos encontrar requisitos del tipo:

  • Funcionales: indican los servicios y prestaciones concretas que el sistema debe ofrecer al usuario.

  • No funcionales: indican restricciones o características relacionadas con la confiabilidad y seguridad del sistema.

  • De información: indican qué tipo de información debe almacenar y manipular el sistema, y cuáles son sus componentes y características.

• Audiencia: indica a qué tipo de audiencia va dirigida la información que captura el requisito. Se distinguen dos tipos de audiencia:

  • Clientes y usuarios.

  • Desarrolladores.

Jerarquía de los requisitos

1. Requisitos de negocio: expresan por qué una organización desea desarrollar una sistema (objetivos).

2. Requisitos de usuario: describen qué desean hacer los usuarios con el sistema (necesidades y objetivos personales).

3. Requisitos funcionales: indican qué deben implementar los desarrolladores para que los usuarios alcancen sus objetivos. En ocasiones también indican lo que el sistema no debe hacer.

4. Requisitos no funcionales: son limitaciones sobre servicios o funciones que ofrece el sistema.

   • Aspectos legislativos.

   • Aspectos de proceso.

   • Lenguajes y tecnologías.

   NO SON FUNCIONALIDADES CONCRETAS, PERO PUEDEN GENERARLAS.

    

Ejemplo de requisitos de una aplicación de videoconferencia:

Dimensiones de la Ingeniería de requisitos

Se identifican tres dimensiones fundamentales en la ingeniería de requisitos, y cada una de ellas tiene asociado un objetivo determinado:

• Contenido (content): conocer todos los requisitos de manera explícita y comprenderlos con el nivel de detalle requerido.

• Acuerdo (agreement): establecer un nivel de acuerdo suficiente sobre los requisitos entre las partes implicadas.

• Documentación (documentation): documentar y formalizar todos los requisitos según los formatos definidos.

Proceso de ingeniería de requisitos

La ingeniería de requisitos es la primera de las actividades básicas de la ingeniería del software y la más fundamental de todas.

Dentro de los distintos modelos de proceso podemos identificar distintas actividades y configuraciones

La ingeniería de requisitos tiene como producto final un documento que contiene una especificación formalizada de los requisitos que los interesados desean.

Podemos distinguir dos tipos de audiencia principales:

• Clientes y usuarios finales: reflejan sus necesidades.

• Equipo de desarrollo: necesitan una descripción más detallada y precisa.

Modelos de proceso

Proceso iterativo e incremental (Sommerville 2005)

Sommerville identifica 4 actividades:

• Estudio de viavilidad.

• Obtención y análisis de requisitos.

• Especificación de requisitos.

• Validación de requisitos.

Proceso iterativo (Wiegers y Beatty 2013)

Este modelo no contempla el estudio de viabilidad como parte del proceso, si no como una actividad previa al comienzo del proyecto. Una vez obtenido el informe de viabilidad positivo, las actividades de elicitación, análisis, especificación y validación están fuertemente acopladas entre sí.

Proceso en espiral (Somerville 2011)

El modelo en espiral resalta la naturaleza iterativa e incremental del proceso.

Analista de negocio

El analista de negocio es el individuo que tiene la principal responsabilidad de elicitar, analizar, documentar y validar las necesidades de los stakeholders del proyecto.

Es el intermediador entre los clientes y el equipo de desarrollo.

NO ES UN JEFE DE PROYECTO, pues este gestiona la información relativa al proyecto, mientras que el analista de negocio recolecta y disemina información sobre el producto.

Tareas fundamentales del analista de negocio

• Definir los requisitos de negocio.

• Planificar las actividades de la ingeniería de requisitos.

• Identificar a los stakeholders.

• Elicitar los requisitos.

• Documentar los requisitos.

• Comunicar los requisitos.

• Liderar la validación.

• Facilitar la priorización.

• Gestionar los requisitos.